Telecommunications network operators rely heavily on the integrity of their fiber cable networks in competing for customers on the basis of quality of service. Carriers can no longer tolerate service outages on cables, or even single fibers, designed to transport numerous gigabit-per-second optical channels.
Once an optical cable has been installed, network providers must be certain that each separate fiber span matches or exceeds the carrier's specifications. Testing and troubleshooting of in situ optical fiber cable is frequently carried out using optical time domain reflectometer (OTDR) instruments, such as the Series FTB-7000B ODTR sold by EXFO Electro-Optical Engineering Inc. of Vanier (Quebec) Canada.
The OTDR characterizes fibers at a high level of detail, generating distance versus attenuation data, as well as insertion loss measurements for all splices, defects, kinks, and breaks. An OTDR functions by injecting a short, intense laser pulse into the optical fiber and measuring the backscatter and reflection of light as a function of time. A simplified, schematic representation of an OTDR 110 is shown in FIG. 1. The OTDR includes a laser source 116 and a detector 117, each connected to a subject fiber 100 via a coupler 118. Laser energy is injected into the fiber 100 in the form of hundreds of pulses per second. A portion of the laser energy travels to the fiber termination, but splices, breaks, bends and any other anomalies in the fiber reflect some portion of the laser energy. Those characteristics can be located along the fiber by observing the round trip transmission time of the reflected laser energy. The characteristics are measured thousands of times and averaged to increase accuracy.
The reflected light characteristics are analyzed to determine the location of any fiber optic breaks or splice losses. FIG. 2 shows a sample output trace of a typical OTDR. Distance along the fiber cable is represented in kilometers on the x-axis 210, and attenuation 220 of the Laser signal is represented in decibels on the y-axis 212.
Many of the characteristics seen on an OTDR trace are the result of Fresnel reflectance caused by abrupt changes in the index of refraction (ex: glass/air). For example, the mechanical splice connector 221 and span end 223 shown in the trace of FIG. 2 are the result of glass/air interfaces. Using the location of the span end 223 on the x-axis, a length of the fiber span may be accurately calculated. A fusion splice 222 eliminates a glass/air interface, but it nevertheless generates a substantial level of reflected signal power as compared to the backscatter level, and is detectable on the trace. Floor noise 224 may be seen at distances beyond the termination 120 (FIG. 1) of the fiber.
The proper interpretation of OTDR data—whether generated manually or automatically—frequently depends upon its comparison to one or more reference traces. A reference trace, however, is a static snapshot of a fiber that quickly becomes out of date, both from aging characteristics of the optical material, and as a result of network maintenance.
For example, a test OTDR trace may be compared to a reference trace, and the test trace may reveal a shorter overall fiber length than that shown by the reference trace. That situation raises the question whether the shorter fiber length is due to an accidental cable cut, or is due to a cable loop being removed in the course of normal network operations. Similarly, if a test trace displays a higher loss reading, the question arises whether this an equipment fault, or is simply aging of the fiber.
A wide body of tools exists in the industry to analyze a test trace, and to compare that trace to an assumed good reference. However, working in the reverse direction—comparing the reference to the newer test trace—gives a significant advantage to the process.
There is presently a need for a set of statistical tools to increase confidence in the comparison and analysis of OTDR data. Those tools should permit the automatic detection of certain conditions such as:
Reference Trace is invalid and must be updated; and
Reference Trace is valid, but test trace is suspect.
Even if both traces are valid, the toolset should allow additional information to be extracted from the test trace, such as a possible future failure type or failure point.